d2) United States Patent 

Monacos et al. 



US009070268B2 


(io) Patent No.: US 9,070,268 B2 

(45) Date of Patent: Jun. 30, 2015 


(54) WIRELESS SENSOR NODE FOR 

AUTONOMOUS MONITORING AND ALERTS 
IN REMOTE ENVIRONMENTS 

(71) Applicant: California Institute of Technology, 

Pasadena, CA (US) 

(72) Inventors: Steve P. Monacos, Altadena, CA (US); 

Anand V. Panangadan, Monterey Park, 
CA (US) 

(73) Assignee: California Institute of Technology, 

Pasadena, CA (US) 

( * ) Notice: Subject to any disclaimer, the term of this 

patent is extended or adjusted under 35 
U.S.C. 154(b) by 16 days. 

(21) Appl.No.: 14/068,303 

(22) Filed: Oct. 31, 2013 

(65) Prior Publication Data 

US 2014/01 18143 Al May 1,2014 


Related U.S. Application Data 

(60) Provisional application No. 61/720,899, filed on Oct. 
31,2012. 


(51) Int.Cl. 

G08B 1/08 (2006.01) 

G08B 25/01 (2006.01) 

G08B 21/02 (2006.01) 

(52) U.S. Cl. 

CPC G08B 25/016 (2013.01); G08B 21/02 

(2013.01) 


(58) Field of Classification Search 

CPC .. G08B 25/016; G08B 21/02; G08B 21/0258; 

G08B 21/0261; G08B 21/0269; G08B 
21/0277; G08B 21/0283; G08B 21/0286; 

G08B 21/0288; G01S 5/0054 


USPC 340/573.1,573.4,539.13,539.11,522, 

340/539.12, 586, 692, 693.2, 693.1, 693.5; 
455/404.1, 404.2; 379/37, 38, 39, 43, 

379/45 

See application file for complete search history. 

(56) References Cited 

U.S. PATENT DOCUMENTS 


7,330,122 B2 * 2/2008 Derrick etal 340/573.1 

7,652,571 B2 * 1/2010 Parkulo et al 340/540 

8,599,011 B2 * 12/2013 Schantz et al 340/539.13 

2009/0174547 Al * 7/2009 Greene et al 340/539.13 


OTHER PUBLICATIONS 

Gnawali, O., et al., “Collection Tree Protocol”, Proceedings of the 7th 
ACM Conference on Embedded Networked Sensor Systems 
(SenSys), Berkeley, CA, Nov. 4-6, 2009. 

(Continued) 

Primary Examiner — Anil V La 

(74) Attorney, Agent, or Firm — Gates & Cooper LLP 

(57) ABSTRACT 

A method, apparatus, system, and computer program prod- 
ucts provides personal alert and tracking capabilities using 
one or more nodes. Each node includes radio transceiver 
chips operating at different frequency ranges, a power ampli- 
fier, sensors, a display, and embedded software. The chips 
enable the node to operate as either a mobile sensor node or a 
relay base station node while providing a long distance relay 
link between nodes. The power amplifier enables a line-of- 
sight communication between the one or more nodes. The 
sensors provide a GPS signal, temperature, and accelerom- 
eter information (used to trigger an alert condition). The 
embedded software captures and processes the sensor infor- 
mation, provides a multi-hop packet routing protocol to relay 
the sensor information to and receive alert information from 
a command center, and to display the alert information on the 
display. 

24 Claims, 14 Drawing Sheets 
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WIRELESS SENSOR NODE FOR 

AUTONOMOUS MONITORING AND ALERTS 
IN REMOTE ENVIRONMENTS 

CROSS-REFERENCE TO RELATED 5 

APPLICATIONS 

This application claims the benefit under 35 U.S.C. Section 
1 1 9(e) of the following co-pending and commonly-assigned 
U.S. provisional patent application(s), which is/are incorpo- 10 
rated by reference herein: 

Provisional Application Ser. No. 61/720,899, filed on Oct. 

31, 2012, by Steven P. Monacos and Anand V. Panangadan, 
entitled “Wireless Sensor Node for Autonomous Monitoring 
and Alerts in Remote Environments”. 15 

STATEMENT REGARDING FEDERALLY 

SPONSORED RESEARCH AND DEVELOPMENT 

The invention described herein was made in the perfor- 20 
mance of work under a NASA contract, and is subject to the 
provisions of Public law 96-517 (35 USC 202) in which the 
Contractor has elected to retain title. 

BACKGROUND OF THE INVENTION 25 

1. Field of the Invention 

The present invention relates generally to tracking people/ 
nodes, and in particular, to a method, apparatus, system, and 
article of manufacture for low-power wireless nodes that 30 
provide tracing of the position of the nodes. 

2. Description of the Related Art 

(Note: This application references a number of different 
publications as indicated throughout the specification by ref- 
erence numbers enclosed in brackets, e.g., [x], A list of these 35 
different publications ordered according to these reference 
numbers can be found below in the section entitled “Refer- 
ences.” Each of these publications is incorporated by refer- 
ence herein.) 

The current radio infrastructure for wild land firefighter 40 
personnel provides voice communications but does not sup- 
port data transfer capability for continuous monitoring of 
personnel in the field. Current radios require user interaction 
to perform manual voice check in for firefighter status. A new 
infrastructure is required to enable continuous, autonomous 45 
monitoring of firefighter personnel during a firelight via a 
remote command and control center. The system additionally 
needs to provide the capability to send 2-way alerts to provide 
early warning of impending danger to persomiel in real-time 
and for indication of an emergency in the field due to a 50 
downed firefighter(s). To better understand such problems, a 
description of prior art tracking requirements and systems 
may be useful. 

Preserving the safety of first responders in the field is of 
utmost importance. One component of safety systems 55 
attempts to track the location of first responders along with 
attempting to provide alerts both to and from such first 
responders. Unfortunately, prior art tracking systems often 
fail and/or are unable to determine the location of a first 
responder. In view of the above, as used herein, first respond- 60 
ers include firefighters (e.g., wild land firefighters in forest 
fire environments), forest services, urban search and rescue 
groups, etc. In addition, it may be useful to track other persons 
such as soldiers in the field, hikers, mountain bikers, animals 
(e.g., tagged mountain lions, bears, etc.), etc. However, many 65 
environments (in which it is desirable to track such persons/ 
animals) have a vast area, a lack of infrastructure, and very 


2 

rough terrain. Further, it is desirable to track such persons/ 
animals based on standard (fire fighter) supplies such as AA 
batteries, while also visualizing the person/animal location 
on a map-based display, along with the ability to receive alerts 
from such persona and send messages back to such persons 
via a graphical user interface. 

One prior art radio based system is the Geospatial Location 
Accountability and Navigation System for Emergency 
Responders (GLANSER™). Glanser™ is designed for 
indoor applications, is carried on a firefighter, and consists of 
a radio, a battery (e.g., AA), and a suite of navigation devices 
for embedded tracking Two-way signals are transmitted at 
900 MHz frequency by a USB-powered base laptop station in 
a fire truck to monitor firefighters. 

Another prior art system is the Physiological Health 
Assessment System for Emergency Responders 
(PHASER™). Phaser™ monitors a firefighter’s body tem- 
perature, blood pressure, and pulse. An alarm sounds on a 
laptop if the firefighter is in trouble and the location can be 
found via Glanser™. 

A further prior art system is the Wireless Intelligent Sensor 
Platform for Emergency Responders (WISPER™). Wisper™ 
is a 1 -inch-square, Vi-inch thick, throwaway router that con- 
tains a two-way digital radio, antenna and 3-volt lithium cell. 
The routers form an ad-hoc mesh network. However, such 
routers are relatively short range and are designed to work 
indoors. 

Further prior art systems include satellite-based commu- 
nication systems. Such systems require high power transmit- 
ters that consume power. Accordingly, the continuous trans- 
mission of data in such systems is not practical. For example, 
the Delorme™ InReach™ system has a maximum update rate 
of about two minutes. The Delorme™ InReach™ system also 
designates delivery (of up to three pre-loaded messages) to 
email, cell phones, Facebook™, or Twitter™ and sends an 
SOS with the GPS location (with delivery confirmation 
received for all messages via LED). The Delorme™ systems 
provides the ability for others to track a person’s progress 
online for mutual peace of mind. However, Delorme™ sys- 
tems require user interaction and the use of a satellite link can 
result in a permanently obstructed signal due to rubble (re- 
gardless of proximity). In addition, transmitting large 
amounts of sensor data also consumes power. Hence, adding 
sensors is difficult. Further, clear line-of-sight to the sky is 
required for satellite-based communication. Consequently, 
no communication is possible if there is an obstruction, even 
if there is a nearby node. 

In view of the above, it is desirable to have a system that has 
robust data relay between persons (e.g., first responders)/ 
animals and a command center along with two way alerts and 
warning on incident command systems. Such capabilities are 
not currently available in traditional wild land firefighting 
radios. In addition, it is desirable to have a low power design 
that utilizes a wide range of sensors (e.g., environmental 
parameters and GPS location). Further, it is desirable to pro- 
vide a visualization of person/animal locations on a map- 
based display with the ability to receive alerts from persons 
and send messages back to such persons from the graphical 
user interface. 

SUMMARY OF THE INVENTION 

Prior art radios used by firefighters provide for voice com- 
munications but do not support the capability for data han- 
dling or to monitor the movements and status of firefighters 
while in the field fighting fires. Due to the lack of such a 
co mmu nications infrastructure in such remote environments, 
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embodiments of the invention provide an autonomous wire- 
less sensor network (referred to as the personal alert and 
tracking system (PATS)) for tracking first responders (e.g., 
firefighters) operating in the field (e.g., wild land fire envi- 
ronments) with minimal intervention by the first responders. 

PATS consist of a networked collection of custom-de- 
signed low -power wireless nodes that provide tracking of the 
position of the nodes. A PATS node is capable of transmitting 
sensor information and receiving visual/audible alerts and 
warnings over an extended rugged area. The nodes are 
equipped with onboard GPS, temperature, and accelerometer 
sensors with the ability to interface additional sensors as 
needed to each node. Mobile nodes form arbitrary network 
topologies and use a multi-hop packet routing protocol to 
relay sensor data to the command center. The multi-hop capa- 
bility enables robust communication in a variety of environ- 
ments by routing around natural and man-made terrain fea- 
tures. PATS nodes are capable of communication over several 
kilometers with burst rates of tens of kilobits per second. 
Embedded software on each node captures, processes and 
routes sensor data through the PATS network and displays 
alert information to the person carrying the node. 

In view of the above, embodiments of the invention 
includes multiple sensor nodes, a base station node, and a 
graphical user interface (GUI). The sensor nodes and base 
station may use the same hardware but with minor variations 
to accommodate the different functionality. Additionally, the 
software utilized by the sensor and base station nodes may be 
different to accommodate the functionality specific to each 
node type. The PATS network is accessed through a web- 
based GUI (referred to as Situational Awareness and Predic- 
tion [SAP] ), that is a client-server based application to pro- 
vide web-based capability. 

The wireless, small-forum node includes integrated sen- 
sors as part of an ad-hoc wireless mesh network to collect 
real-time telemetry from the sensor of the node. The node also 
incorporates a user interface for receiving audible and visual 
alerts and sending an alert signal when an emergency situa- 
tion occurs. The node incorporates spatial and frequency 
hopping capability with periodic updates of the local network 
topology to allow for rerouting of telemetry data and alerts as 
the network topology changes due to movements of the nodes 
and/ or nodes being powered up or down. Telemetry data from 
the network is ultimately sent to a remote command center via 
a long distance repeater link and/or internet connection to a 
web-based server for personnel status and to broadcast alerts 
back to the nodes for impending dangerous conditions requir- 
ing immediate action. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Referring now to the drawings in which like reference 
numbers represent corresponding parts throughout: 

FIG. 1 illustrates an exemplary PATS multi-tier communi- 
cation architecture utilized in accordance with one or more 
embodiments of the invention; 

FIG. 2 illustrates a different viewpoint of the communica- 
tion architecture of PATS in accordance with one or more 
embodiments of the invention; 

FIG. 3 illustrates a compact configuration of the PATS 
nodes in accordance with one or more embodiments of the 
invention; 

FIG. 4 illustrates a grid configuration of the PATS nodes in 
accordance with one or more embodiments of the invention; 

FIG. 5 illustrates the row configuration of the PATS nodes 
in accordance with one or more embodiments of the inven- 
tion; 
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FIG. 6 illustrates a block diagram of a PATS sensor node in 
accordance with one or more embodiments of the invention; 

FIG. 7 illustrates external features of the PATS node in 
accordance with one or more embodiments of the invention; 
5 FIG. 8 illustrates the sensor chassis layout in accordance 
with one more embodiments of the invention; 

FIG. 9 illustrates a TinyOS™ mapping between a top-level 
application (i.e. component) and a low-level configuration 
(i.e. platform) in accordance with one or more embodiments 
to of the invention; 

FIGS. 10A-10B show the SAP GUI (Situational Awareness 
and Prediction Graphical User Interface) graphical display 
showing the “Earth-view” and localized locations of nodes in 
the theater of operation, alert status of nodes and pop-up 
15 display with detailed telemetry in accordance with one or 
more embodiments of the invention; 

FIG. 11 is an exemplary hardware and software environ- 
ment used to implement one or more embodiments of the 
invention; 

20 FIG. 12 schematically illustrates a typical distributed com- 

puter system using a network to connect client computers to 
server computers in accordance with one or more embodi- 
ments of the invention; and 

FIG. 13 is a flow chart illustrating the logical flow for 
25 tracking a position of one or more nodes in accordance with 
one or more embodiments of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

30 

In the following description, reference is made to the 
accompanying drawings which form a part hereof, and which 
is shown, by way of illustration, several embodiments of the 
present invention. It is understood that other embodiments 
35 may be utilized and structural changes may be made without 
departing from the scope of the present invention. 

Overview 

A Personal Alert and Tracking System (PATS) consists of 
a networked collection of custom-designed low-power wire- 
40 less nodes that provide tracking of the position of the nodes. 
A PATS node is capable of transmitting sensor information 
and receiving visual/audible alerts and warnings over an 
extended rugged area. The nodes are equipped with onboard 
GPS (global positioning system), temperature, and acceler- 
45 ometer sensors with the ability to interface additional sensors 
as needed to each node. Mobile nodes form arbitrary network 
topologies and use a multi -hop packet routing protocol to 
relay sensor data to the command center. The multi-hop capa- 
bility enables robust communication in a variety of environ- 
50 ments by routing around natural and man-made terrain fea- 
tures. PATS nodes are capable of communication over several 
kilometers with burst rates of tens of kilobits per second. 
Embedded software on each node captures, processes and 
routes sensor data, and displays alert information to the per- 
55 son carrying the node. 

PATS integrates several different technologies to imple- 
ment a system that is capable of relaying information between 
widely distributed entities such as between frontline wild 
land firefighters and remote command centers. PATS nodes 
60 may be mobile and the mesh networking technology is able to 
autonomously route data via a self-organizing network. The 
PATS node hardware design integrates all processing, sens- 
ing, communication, and display components into one 
device. The hardware design is extensible and headers are 
65 available for interfacing with external sensors and radios. 

In particular, embodiments of the invention provide a 
design that includes two radio transceiver chips that enable 
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operation at two different frequency ranges — 902-928 MHz 
ISM band and 400 MHz licensed band. These two radios 
enable the same hardware device to operate as either a mobile 
sensor node or a relay base station. The PATS node includes 
a RF (radio frequency) power amplifier that enables a line- 5 
of-sight communication range of 2 km between two nodes in 
the 902-928 MHz frequency range. 

FCC (Federal Communications Commission) regulations 
limit the amount of continuous power that can be transmitted 
in one channel to 1 mW or less (FCC Part 15, 15.247). To 10 
operate at higher powers, PATS implements frequency hop- 
ping so that communication in each band is limited to 40 ms 
duration as required by the FCC regulations. The time syn- 
chronization needed to maintain the time slots of the distrib- 15 
uted sensor nodes for frequency hopping is provided by the 
GPS signal. Thus, PATS integrates the spatial multi-hopping 
protocol (Collection Tree Protocol) with the frequency hop- 
ping protocol to provide a spatial multi-hopping system with 
2 km range at each hop. PATS can operate without the fre- 20 
quency hopping mechanism; in this case, the transmit power 
may be limited to 1 mW (for a few hundred meters range at 
each hop). 

System Architecture 

Embodiments of the invention provide an ad-hoc wireless 25 
sensor network with the following functionality: 

2D tracking and visualization of first responders (e.g., wild 
land firefighters) with 2-way alerts and warning on inci- 
dent command systems not currently available with tra- 
ditional wild land firefighting radios; 30 

A robust sensor web to relay information between front 
line wild land firefighters and the incident command 
center; and 

A sensor web design using a 2-tier system where Tier 1 is 
the firefighter mesh network and Tier 2 is the first level 35 
command-control. 

Such functionality is achieved using sensor and base sta- 
tion nodes. 

Sensor nodes have the following features: 

Embedded code to collect data from onboard accelerom- 40 
eter, temperature and GPS sensors; 

User interface includes a l"xl" Organic Light Emitting 
Diode (OLED) text display and LED with buzzer for 
audible/visual alerts; 

Local ad hoc network operation in the 915 MHz Industrial, 45 
Scientific and Medical (ISM) band; and 
Small handheld sensor node measuring 5"x3.1"xl" (ex- 
cluding antenna) and weighing less than V 2 kg. 

Base station nodes may have the following features: 

Small handheld node measuring 5"x3.1"xl" (excluding 50 
antenna) and weighing less than Vi kg; 

Connects to a laptop/PC and has embedded code to collect 
network data and transmit text/alerts to the network; 
Laptop bridge code may be used to interface a laptop 
computer to the base station node. 55 

Further, a web-based Graphical User Interface (GUI) may 
be used to monitor sensor nodes and send alerts to the nodes 
to relay emergency conditions 

FIG. 1 illustrates an exemplary PATS multi-tier communi- 
cation architecture utilized in accordance with one or more 60 
embodiments of the invention. 

Tier 1 102 is a local first responder (e.g., firefighter) group 
with dynamic multi-hop routing. More specifically, tier 1102 
consists of the 915 MHz multi-hop network with direct com- 
munication between the sensor nodes 104 carried by the first 65 
responders (e.g., firefighters) in the field to collect telemetry/ 
alerts and disseminate commands to other nodes. Tier 2 112 
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includes the 433 MHz relay link 118 and remote command 
center 116 with the GUI for monitor and control of the tier 1 
network 102. 

More specifically, tier 1 102 consists of an ad-hoc mesh 
network of PATS nodes 104 (also referred to as network 
nodes). A PATS node 104 is a portable device with sensors 
106 , radios 108 , microcontroller, and embedded software 
110 . The first responder units/network nodes 104 provide for 
multi-hop routing (space/frequency) of sensor data to a relay 
node 120 . The relay radio 118 transfers information from the 
multi-hop network using a longer range dedicated point-to- 
point communications path to a distant incident command 
center 116 . 

The nodes 104/120 can autonomously self-organize in to a 
multi-hop network 1 02 and relay sensor data to a Base Station 
Node 114 e.g., via relay node 120 ). Hie distance between 
each pair of nodes 104/120 can be up to 2 km between first 
responders for line-of-sight communication. The ad hoc rout- 
ing accommodates random first responder movements and an 
arbitrarily laige extent of first responder groups. The obstruc- 
tions between first responders are circumvented by a dynamic 
multi-hop protocol. Mesh networking at Tier 1 102 is con- 
ducted in the 902-928 MHz radio frequency range. 

Tier 2 112 is a long distance (tens of km) repeater network 
to a command center 116 . The relay radio 118 (within a relay 
node 120) can transfer information from the multi-hop sensor 
network 102 using a longer range, dedicated point-to-point 
communications path to a distant incident command center 
116 . Radio communication at 433 MHz will potentially be 
used for long-range relay link. 

Accordingly, tier 1 102 and tier 2 112 work together to 
provide communication between first responders in the field 
and a command center 116 . At Tier 1 102 , ad-hoc mobile 
multi-hop networking is used to collect sensor data from the 
handheld units and forward them to a central base station 
node 114 . Multi-hop networking is also used to forward text 
messages from the base station 1 1 4 to selected or all handheld 
units 104 . Multi-hop communication is necessary in a web- 
enabled sensor network when an embedded sensor node 104 
is out of range of the nearest communication node with web 
access. In such cases, the sensor data should be routed via 
intermediate embedded sensor nodes (e.g., network nodes 
104 or relay nodes 120 ). In such a scenario, the spatial extent 
of the sensor web is limited only by number of intermediate 
nodes (where the range is the number of hops times the radio 
range of a single sensor node). 

FIG. 2 illustrates a different viewpoint of the communica- 
tion architecture of PATS in accordance with one or more 
embodiments of the invention. FIG. 2 shows the end-to-end 
communication design of the PATS system. Data from the 
first responders passes through multiple levels before it 
reaches the graphical user interface. 

In a multi -hop communication level 202 , data originates 
from the sensors on the network nodes 2 04 carried by the first 
responders and is dynamically routed through other nodes 
204 using wireless communication to reach a base station. 
The base station can also send text messages back to indi- 
vidual network nodes 204 using multi-hop routing. 

A second level is that of long distance communication 206 . 
At level 206 , all of the sensor data from the first responders 
(i.e., network nodes 204 ) is transmitted between two base 
stations over a long distance (e.g., tens of km) using a pair of 
relay radios 208 . 

A third level is that of the PATS-SAP bridge 210 . At level 
210 , all of the data from a basestation is transformed into the 
format expected by the SAP server 212 (e.g., via a computer 
214 ) and then transferred to the server 212 over the internet 
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216. The data may then be visualized on a web browser or 
other presentation device 218. Such a web browser or presen- 
tation software may be executing on a hand-held computer 
such as a tablet computer. Hie browser 218 communicates 
with the SAP server 212 over the Internet 216 to show only the 5 
data requested by a user. 

Multi-Hop Communication 

Multi-hop routing is necessary when a sensor/network 
node 104/204 is out of range or out of line-of-sight of the base 
station 114. In this case, data is routed via intermediate sensor to 
nodes 104/204. The range is thus limited only by the number 
of intermediate nodes 104/204. The multi-hop routing proto- 
col automatically re-route data as nodes 104/204 move and 
new sensor nodes 104/204 may join the network 102/202 at 
any time. Thus, dynamic multi-hop routing of data between 15 
sensor nodes 104/204 enables routing around obstructions, 
accommodates random firefighter movements, and scaling to 
large number of firefighters. 

PATS uses the Collection Tree Protocol (CTP) [1] as the 
multi-hop routing methodology for moving sensor data from 
the PATS nodes 104/204 to the base station 114. In this 20 
methodology, data from all sensor nodes 104/204 in the net- 
work 102 is forwarded to a sink node, which in the case of 
PATS is a single base station node 114 (or a pre-defined set of 
base station nodes 114). CTP is a tree-based routing protocol, 
where each remote node 104/204 keeps track of which of its 25 
neighboring nodes 104/204 is closest to the base station 114. 

A remote node 104/204 then sends out packets through this 
neighbor. Nodes 104/204 thus form a routing tree to the sink 
node 114. CTP is called an address-free protocol as all pack- 
ets move toward the sink node 1 14 by choosing only the next 30 
hop. Nodes 104/204 generate routes to the sink 114 using a 
routing gradient. 

The CTP uses link quality estimates provided by the radio 
(while sending and receiving packets) to determine how close 
neighboring nodes 104/204 are. Thus, CTP uses link quality 35 
estimates provided by the radio transceiver to determine how- 
close neighboring nodes are. The link quality is obtained 
while sending and receiving packets. Each sensor node 104/ 
120 keeps track of which of its neighboring nodes is closest to 
the base station 114 and data packets are sent out though this 
neighbor (this defines the next “hop”). CTP also enables route 41 J 
discovery and thus the sensor network can automatically 
adapt to changes in node layout. It can automatically reroute 
data as nodes are moved and new sensor nodes can join the 
network at any time. 

CTP is a best effort protocol (i.e. it does not guarantee 45 
100% reliable delivery). However, CTP has several mecha- 
nisms to improve delivery reliability. High packet delivery/ 
receipt rates (90-99.9%) have been observed in test-beds with 
over 100 nodes 104/204. The CTP protocol may be imple- 
mented in the TinyOS™ operating system (the embedded 50 
operating system that runs on the PATS sensor nodes 104/204 
and base station node 114). 

Multi-hop communication is also used to send alert mes- 
sages from the command center 116 back via the base station 
114 to individual PATS sensor nodes 104/204. The selected 
protocol for distributing alert messages is the default dissemi- 
nation methodology [2] distributed with the TinyOS™ oper- 
ating system. The methodology distributes “small” values to 
all nodes, where “small” denotes that data must fit within one 
packet. This corresponds to a payload of twenty (20) bytes. 
The alert message will include the destination ID; only nodes 
with the corresponding ID will display the alert message. 
Thus, the dissemination routing methodology [2] may be 
used to distribute text messages to a set of selected sensor 
nodes. The dissemination methodology is the converse of the 
Collection methodology (CTP) that is used to route sensor 65 
data packets to the base station 114. The dissemination meth- 
odology is a flooding method in that no route information is 
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maintained at (any of the) nodes 104/204. A complete point- 
to-point routing protocol (e.g., a Tymo methodology that may 
be implemented in TinyOS™) may also be used. 

The multi -hop co mmu nication may also use a TI (Texas 
Instruments) CC1 101 transceiver and TI CCl 190 RF power 
amplifier on the PATS node. The line-of-sight range between 
two PATS nodes is approximately 2 km when the transmis- 
sion power is 0.5 W. 

In view of the above, embodiments of the invention utilize 
the CTP as the multi-hop routing protocol to route data pack- 
ets from sensor nodes 104/204 (carried by first responders) to 
a single data collection node 208, which will then relay all 
data over a long-range link to the central observation location. 
The throughput of the CTP protocol is characterized as the 
number of sensor nodes 104/204 increases and various sys- 
tem parameters and operational conditions are changed. 
These parameters and conditions may include: 

1. Communication topology of the nodes 104/204: 
Depending on the geographic location of the nodes 104/ 
204 and the radio communication range, the connectiv- 
ity between nodes 104/204 will vary; 

2. Size of data packet: Depends on the amount of sensor 
information to be transmitted and routing protocol over- 
head; 

3. Data rate: The data rate determines the proportion of 
bandwidth consumed by transmitting one packet. This 
determines contention for the common access commu- 
nication medium; and 

4. Data transmission frequency: This parameter determines 
how often data packets have to be moved from the sensor 
node to the data collection node. This parameter, 
together with the data rate, determines contention for the 
common access communication medium. 

Sensor network simulation software may be used to model 
the specifics of the CTP routing protocol in a variety of 
configurations. Such software may include an advanced 
channel model based on empirically measured data. This 
model accounts for temporal variation of path loss and inter- 
ference. The radio model may be based on real radios for 
low-power communication. The probability of reception is 
based on SNR (signal to noise ratio), packet size, and modu- 
lation type (PSK [phase shift keying] or FSK [frequency shift 
keying]). Nodes can also be mobile. The CTP model may be 
defined for the CC2420 radio which has a fixed bitrate of 250 
kbps and operates at 2.4 GHz. PATS may also use the CCl 101 
radio at 9 1 5 MHz and has a higher output power. The appro- 
priate CCl 101 radio parameters may be programmed into a 
simulator and the path loss may be changed from 2.4 GHz to 
915 MHz. 

Simulation parameters may be set such that the radio com- 
munication range is set to 1000 m with an ideal modulation 
scheme (i.e., without a time-varying noise component). To 
conduct a simulation, up to 50 nodes may be deployed in one 
of three configurations: a compact configuration, a grid con- 
figuration, and a row configuration. 

FIG. 3 illustrates a compact configuration in accordance 
with one or more embodiments of the invention. In the com- 
pact configuration, all (sensor) nodes 302 were within direct 
radio communication range of the data collection node 304. 
In this configuration, all the transmitting nodes directly con- 
tend for a single common access medium. The arc 306 shows 
the range of the data collection node’s 304 radio (encom- 
passes all of the sensor nodes). 

FIG. 4 illustrates a grid configuration in accordance with 
one or more embodiments of the invention. In the grid con- 
figuration, the (sensor) nodes 402 are arranged in a grid with 
cell distance set to 450 m. Each node 402 can directly com- 
municate with only a subset of the sensor nodes 402 (i.e. those 
within 1000 m of its position) and multi-hop communication 
is required to move data from distant nodes 402 to the data 
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collection node 404. The circle 406 centered at the data col- 
lection node 404 shows the range of its radio. 

FIG. 5 illustrates the row configuration in accordance with 
one or more embodiments of the invention. In the row con- 
figuration, the nodes 502-504 are arranged in a row with the 5 
data collection node 504 at one end and the inter-node dis- 
tance set such that each sensor node 502 can communicate to 
only the two nodes on either side of it. The circles 506 show 
the range of each node’s radio. 

Long Distance Communication to 

Commercial Free Wave LRS455 radios 208 may be used in 
the field for the long-range relay 120/206 between the multi- 
hop network base station node 114 and an Internet-accessible 
computer that acts as the PATS-SAP bridge 214. A pair of 
LRS455 radios, operating in the 435-465 MFlz industrial 15 
band, inserted between the PATS base station node 114 and a 
laptop 214 running the bridge code can communicate telem- 
etry data/control between the PATS network and the SAP 
server 212 over an extended range (up to 70 miles). Such a 
setup may require a 3.3V UART to RS-232 adapter with null , f) 
modem to connect the PATS base station node 114 to one 
LRS455 radio, and a serial to USB adapter to connect the 
second LRS455 radio to a laptop. The LRS455 radios may be 
programmed to operate in a Master-Slave configuration. The 
serial ports of the LRS455 radios may be reprogrammed to 
communicate at 1 15 kbps instead of their default 19.6 kbps. 23 
Such a setup can be used to reliably relay data from a PATS 
sensornode 104/204 to the PATS base station 114 through the 
Freewave™ radios and into the laptop 212 running the PATS- 
SAP bridge code. 

The 433 MFlz onboard radio on the PATS node board can 30 
also be used to set up a similar point-to-point link. However, 
some designs may only allow one-way communication from 
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a PATS multi -hop base station 114 to the bridge laptop com- 
puter 214. In such a configuration, a pair of PATS nodes 
104/204 that are programmed to operate their 433 MHz 
CC1 101 radios is used as the relay link. This type of connec- 
tion requires that the 915 MHz base station 114 be connected 
to the 433 MHz relay node 120 via a crossover UART cable. 
PATS-SAP Bridge 

A PC 214 equipped with a USB port and a connection to the 
Internet 216 is used to transfer data between the multi -hop 
PATS network 202/206 and the Internet-based SAP visual- 
ization and control software 218. The bridge PC 214 is con- 
nected to the PATS base station node 208 via a USB-serial 
cable. Bridge software executes on the bridge PC 214. The 
bridge software reads the bytes coming over the serial link, 
interprets the bytes as sensor measurements, and then relays 
them over a TCP (transmission control protocol) channel to 
the remote SAP server 212. 

Data Formats 

The bridge code will initiate a TCP connection to the SAP 
server 212. The connection will be full duplex to send sensor 
data from the bridge software and receive text messages from 
the GUI 218. The TCP connection is left open forthe duration 
of the sensor data communication session. Tests using a 
single sender showed that even at a packet rate of 1 0 packets/ 
second, packets were received reliably. Thus, the system is 
scalable to at least 50 sensor nodes 104/204 where each 
sensor sends data once every 5 seconds. 

At connection time, the GUI server 218 and the bridge 
software exchange a preamble with the following two ASCII 
bytes: 85, 32. This confirms that both ends of the communi- 
cation channel follow the default TinyOS™ packet protocol. 
Every data packet from the sensor network 202/206 to central 
command after the two connection bytes may have the fol- 
lowing format: 


Java 

Field #bytes type Description 


Length 

NodelD 


Timestamp 


SensorType 


SensorValue 


GPS status 


1 


4 


4 


1 


1 


byte Number of following bytes in the packet. 

This should be 42. 

int Unique identifier of a PATS sensor 

node/firefighter. 

The lowest 8 bits indicate the firefighter 
number within a squad (valid values: 0-254). 
The next higher 8 bits indicate the squad 
number (valid values: 0-255). 
int Unique identifier of a message from a node 

(valid values: 0-65535). Note that messages 
can arrive out of order, i.e., Timestamp of 
successive messages from a node may not 
increase. 

byte Indicates how to interpret the SensorValue 
field. Currently, SensorType = 1 to indicate 
SensorValue is a temperature reading, 
double Sensor measurement. When SensorType = 1 , 
SensorValue is in degrees Celsius. (The 
PATS temperature sensor has a resolution of 
0.0625° C.) 

byte Indicates if valid GPS data is available in 
GPSLatitude, GPSLongitude, GPS time 
fields. GPS status >=10 indicates GPS fields 
contain valid data. 

GPSstatus = 0: GPS fields are invalid; no GPS 
packet received 

GPSstatus = 1 : GPS fields are invalid; no GPS 
fix 

GPSstatus = 2: GPS fields are invalid; 
unrecognized GPS packet 
GPSstatus = 10: GPS fields are valid; GGA 
packet received 

GPSstatus =11: GPS fields are valid; RMC 
packet received 

GPSstatus = 12: GPS fields are valid; GLL 
packet received 
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Field 

#bytes 

Java 

type 

Description 

GPS Latitude 

8 

double 

Latitude in decimal degrees. Valid range is -90.0 
to +90.0. Example value: 34.2014 

GPS Longitude 

8 

double 

Longitude in decimal degrees. Valid range is 
-179.99 to +180.0. Example value: -119.674017 

GPStime_hour 

1 

byte 

Integers between 0 and 23 (UTC time) 

GPStime minute 

1 

byte 

Integers between 0 and 59 (UTC time) 

GP Stime second 

1 

byte 

Integers between 0 and 59 (UTC time) 

GPStime year 

2 

short 

Integer representing 4 digit year (UTC time) 

GP Stime month 

1 

byte 

Oto 11 

GPStime_day 

1 

byte 

1 to 31 

AlertStatus 

1 

byte 

A? Ag A 5 A 4 A 3 A 2 A x A o 
Aq = 1 : firefighter has pressed Alert button 
A4 = 1 : firefighter is Inactive (from 
acceleremoter) 

A 5 = 1 : firefighter is in Freefall (from 
acceleremoter) 

Bits 1-3, 6, 7 are not used. 


The bridge software also accepts text messages from the 
SAP server 212 over the same TCP connection used to send 
sensor data from the nodes 104/204 to the command center. 
Specifically, the data type that is to be distributed is repre- 
sented as a string of ASCII characters along with a destination 
node address. Every data packet from central command to the 
sensor network 202/206 after the two connection bytes may 
be of the format: 


Field 

#bytes 

Java 

type 

Description 

PacketLength 

1 

byte 

Number of bytes to follow (valid 
values will be 7 to 26) 

DestinationNodelD 

4 

int 

Unique identifier of a PATS 
sensor node/firefighter. 

The lowest 8 bits indicate the 
firefighter number within a 
squad (0-254). A value of 255 
indicates a broadcast message 
to all firefighters. 

The next higher 8 bits indicate 
the squad number (valid 
values: 0-255). 

MessageType 

1 

byte 

Set to 0. 

MessageString 

Length 

1 

byte 

Number of bytes in 
MessageString. Valid values: 
1-20. 

MessageString 

1-20 

byte[ ] 

A sequence of ASCII 
characters in the range 32-126. 


Web Browser-Based GUI 

Visualization of sensor data from PATS nodes 104/204 and 
communication of text messages and alert commands to indi- 
vidual PATS nodes 104/204 is made using the SAP Internet- 
based system. Every SAP system has a single server 212, that 
functions as a central repository of SAP operational informa- 
tion. 

Any number of clusters of PATS nodes 102/204, each one 
managed by a single PATS “base station” device 114/208, 
may connect to a single SAP server 212. Within the server 
212, a separate base station thread is spawned to handle 
acquisition of data from each base station 114/208. Likewise, 
any number of SAP users (web clients) may connect concur- 
rently to a single SAP user. Each such connection is termed a 
“session”. Any single session may be in either real-time mode 
or in replay mode at any time. Both the SAP server 212 and an 
SQL server (e.g., a MySQL™ server) may execute within 
cloud machines (e.g., Amazon™ cloud machines). 


Two-Way Communication of Alerts 

The embedded PATS node software and the SAP GUI 
communicate and display alerts between the command center 
and individual sensor nodes 104/204. These specific modes of 
communicating alerts may be implemented: 

1 . Pressing the Alert/alarm switch on a PATS sensor node 
104/204 transmits an alert signal using multi-hop rout- 
ing to the base station node 114/208, transferred overthe 
Internet 216 from the base station 114/208 to the GUI 
server 212 and displayed on the browser-based GUI 218 
using a special Alert icon. 

2. A text message and destination ID entered into the GUI 
218 is forwarded to the base station 114/208; the base 
station 1 14/208 then broadcasts the message to all nodes 
104/204 using multi-hop routing. Only the intended des- 
tination node 1 04/204 acts on the message by displaying 
it on an OLED display, turning on the Alert LED and 
producing beeps on the speaker. 

3. A special text message, “WARNING”, causes the Alert 
LED to flash and the speaker to beep at 2 second inter- 
vals. 

4. A special text message, “DANGER”, causes the Alert 
LED to flash and the speaker to beep at 0.5 second 
intervals. 

A special text message, “CLEAR”, causes the Alert LED to 
stop flashing and the speaker to stop beeping. Receipt of this 
message is acknowledged by the removal of the alert icon 
from the command center GUI. Thus, multi-modal user inter- 
action consists of an alarm switch based on application needs, 
and an integrated graphic display to alert a first responder 
group of an emergency situation. 

Further, a special address of “255” may indicate a message 
is to be sent to all nodes. 

Hardware Design 

As described above, current radios used by firefighters 
provide for voice communications but do not support the 
capability for data handling to monitor the movements and 
status of firefighters and provide alerts to them while in the 
field fighting fires. To implement such a communication 
infrastructure for remote environments required development 
of a compact, wireless sensor node for tracking firefighters’ 
position and status while operating in wild land fire environ- 
ments with minimal intervention by the fire fighters. Uiis 
functionality was achieved with the development of a small 
handheld node with an onboard radio and sensors to monitor 
temperature, acceleration and GPS position. In addition to the 
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sensors, the node also includes a speaker, Light Emitting 
Diode (LED) and Organic LED (OLED) display to provide 
both audible and visual alerts from the incident command 
center back to the firefighters in the field. 

A PATS sensor node 104/204 is designed to collect infor- 5 
mation from a variety of sensors, perform signal processing 
of the sensor measurements, transmit sensor data over the 
network, and receive messages from the network to be dis- 
played to its user. The sensor node 104/204 is intended to be 
carried by a person and so its location can vary in the sensor to 
network. 

FIG. 6 illustrates a block diagram of a PATS sensor node 
104/204 in accordance with one or more embodiments of the 
invention. The PATS hardware design currently includes an 
ultra low power micro controller 602, sensors 604, and two 15 
radio transceivers 606A and 606B. 

The microcontroller 602 (also referred to as a microcon- 
troller unit — MCU) may be from Texas Instrument™’ s low 
power 16-bit MSP430 family of microcontrollers (e.g., TI 
MSP430Fs6 1 7 with 92 KB of Flash memory, 8 KB of SRAM, 20 
four serial ports [configurable as two SPI/I2C ports and two 
UART ports], 8 Analog-to-Digital Converter [ADC] channels 
and numerous digital input/output [I/O] ports). Such a micro- 
controller 602 may use a 3 V power source with up to 1 6 MHz 
clock rates, consume -10 inA of current at the highest clock 25 
rate, and is available in a 113-pin Ball Grid Array (BGA) 
package that is 7.1 nun on a side. The small size, power and 
available digital and analog inputs/outputs make this MCU 
602 a good fit to the PATS node design. The microcontroller 
602 has four digital ports for interfacing digital sensors 604 30 
and the radio transceivers 606. The hardware architecture is 
designed to be upgradeable as the digital and analog ports of 
the microcontroller 602 allow for additional sensors in the 
future. 

As illustrated in FIG. 6, the TI MS430F2617 low power 35 
micro controller 602 is used for the overall controller of the 
node to operate the radio(s) 606, read telemetry from the 
onboard temperature 604B and accelerometer 604A sensors 
and the off-board GPS module 604C and also implement the 
Collection Tree Protocol (CTP) used to perform the ad hoc 40 
routing of the local mesh network. 

Further, the block diagram of FIG. 6 includes the part 
numbers for the major components including the MCU 602, 
radios 606, sensors 604, memory 612 and OLED display 610. 
This functionality of the node board includes onboard pro- 45 
cessing, dual radios 606 (433 MHz and 915 MHz bands) with 
corresponding antemia matching circuits 616, battery charg- 
ing circuitry 614, SPI-based external memory 612 for the 
MCU 602, accelerometer 604A, temperature sensor 604B, 
serial port for a UART-based GPS interface 604C and text 50 
capable display 610. Thus, the MCU node board includes the 
TI MSP430F6217 MCU 602, a 1-Mbit flash memory 
(M25P10-A) 612, 3-axis accelerometer (ADXL345) 604A, 
temperature sensor (TMP1 02) 604B, 128x128 OLED display 
(NL128128C) 610, momentary tactile switch 608 for alerts 55 
and light emitting diodes (LEDs) 618 and 620 for various 
indicators. The tactile switch 608 enables a firefighter to 
communicate an alert condition to the command center in the 
case of an emergency. 

Hie sensors 604 are a 3-axis accelerometer 604A, tempera- 60 
ture sensor 604B, and GPS module 604C. The onboard accel- 
erometer chip 604 A is capable of generating interrupts when 
it detects a free-fall or extended period of inactivity. This 
capability is used to automatically generate and transmit an 
alert condition via the sensor web in case the user suffers a fall 65 
or is immobilized due to an accident. The user can also gen- 
erate an alert condition by pressing a dedicated switch 608. 
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The two radio transceivers 606A and 606B are configured 
to operate in the 902-928 MHz (606A) and 415 MHz (606B) 
range. The 900 MHz radio 606A is used for mesh networking 
at the Tier 1 layer while the 415 MHz radio 606B is to be used 
for a long-distance relay link. A 1" square, 128x128 pixel, 
color display 610 is provided so that text messages can be 
displayed to the user. The node also contains a flash memory 
chip 612 to store up to an hour of sensor data. Thus, when 
there is no radio connectivity, the internal memory may store 
the sensor data and relay the data when connectivity is rees- 
tablished (e.g., thereby providing disruption tolerant net- 
working) The internal memory may utilize a FIFO (first in 
first out) buffer to store the packets during an RF link outage. 
The PATS node is powered using 2 AA batteries. For the node 
design to support the 2-tier PATS network architecture, the 
node design may also incorporate an externally accessible 
UART for use with a Commercial-Off-The-Shelf (COTS) 
433 MHz band radio to implement a long-range relay link. 

Most node components, including the microcontroller 602, 
radios 606, and sensors 604 are integrated into a single circuit 
board. In other words, such a board may have two onboard 
radios 606A and 606B, one for the PATS 915 MHz ISM band 
local mesh network and one for the 433 MHz band radio as a 
backup option to provide the relay link function. 

A separate daughter board may house the OLED display 
610. alert switch 608, display/alert LED 618, and mating 
extension headers forthe ports. Connectors on this board may 
also provide for USB communication via a Serial-to-USB 
cable. All of these components may be supported by the 
TinyOS™ embedded operating system. A JTAG (joint test 
action group) adapter may be available for flash programming 
the microcontroller 602 with embedded software. 

Thus, in view of the above, a PATS node hardware radio/ 
sensor design may include the following components: 
MSP430F6217 micro controller (MCU) 602 
900 MHz radio for tier 1 layer 606A 
400 MHz radio for tier 2 606B 

3-axis accelerometer detects free-fall and inactivity events 

604A 

Temperature sensorat 0.5° C. accuracy and -25° C. to +85° 

C. range 604B 

Power circuitry for operation using 2 AA batteries 614 
GPS module provides 2 m accuracy in latitude/longitude 

604C 

Flash memory to store up to an hour of sensor data 612 
Serial ports for additional radio/sensors 
ABS plastic case rated at 100° C. 

OLED display 610 protected with Lexan plastic 
2xSMA antemia connectors 616A and 616B 
Alert 618 and Power on 620 LEDs 
Alert push-button switch 608 

Free-fall and inactivity detection may be provided. The 
onboard accelerometer (ADXL345 chip) 604A generates 
interrupts when it detects a free-fall and/or extended period of 
inactivity: 

Free-fall event 

All three axes of the accelerometer 604A detect accel- 
eration below a threshold for a period of time; 
Inactivity event 

All three axes of the accelerometer 604A experience a 
change in acceleration of less than a threshold for 
more than a pre-defined time. 

Parameters can be easily changed according to firefighter 
situational parameters. 

The dual radios 606 in the node may both be Chipcon™ 
CC1 101 from TF M with the 915 MHz radio 6906A including 
the CC1190 combination unit 620 which includes a Power 
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Amplifier (PA) and Low Noise Amplifier (LNA). The match- 
ing networks 616 provide maximum power transfer between 
the radio 606 and antenna 622 for the 433 MHz band and the 
PA/LNA 620 and antenna 622 for the 915 MHz band. Both 
radios use 50 ohm antennas 622. The node power circuitry 
614 uses a DC-DC converter to provide a stable 3.5V rail for 
regulators used to drive the radios 606, sensors 604A and 
604B and GPS module 604C even as the battery voltage drops 
over time due to usage. A battery charging circuit may also be 
integrated into the node power circuitry 614 should there be 
utility in using rechargeable cells for the node power pack. 
The charging circuitry may also be able to power the node 
directly. A 3 .3 V RS232 port may also be utilized in the design 
to power and provide communication between the MCU 602 
and plug in GPS module 604C. The node board also includes 
analog/digital interfaces for additional off-board sensors/ra- 
dios, LED indicators 618/620 for the displaying the state of 
the battery if using the charging circuit 614, a piezo speaker 
624 for an audible alarm, IO ports for general purpose digital/ 
analog connections and serial ports including SPI, I 2 C and 
3.3V RS232 interfaces. 

A search of commercially available GPS chips and mod- 
ules identified the ublox C04-6H GPS smart antenna LEA-6H 
Reference design as a good candidate for the GPS module. 
This component provides positional accuracy in the 2 to 5 m 
range, requires a single +5V input voltage with 3V UART 
connectivity and is well suited for interconnection with the 
MSP430F2617 MCU on the PATS node board. 

The physical layout of the sensor node is shown in FIGS. 7, 
and 8. FIG. 7 illustrates external features of the PATS node in 
accordance with one or more embodiments of the invention. 
FIG. 8 illustrates the sensor chassis layout in accordance with 
one more embodiments of the invention. In these figures, the 
OLED Display 610, alert LED 618, and alert switch 608 are 
on the top face of the node. The face plate 702 of the node 
chassis has the SMA connectors 626 for the 433 and 9 1 5 MHz 
radios. For the sensor node, only the 915 MHz radio 606A is 
active. The slider power switch 628 is also placed on the 
chassis faceplate 702 along with a green power LED 620. 
Antenna Design 

In testing radio modules and PATS designed components, 
it was found that the powertransfer to commercially available 
antennas from the radios were very susceptible to external 
factors due to being monopole antennas. The primary reason 
for this issue is that a monopole antenna does not have a 
ground structure to establish the RF field pattern. To remedy 
this situation, embodiments of the invention utilize custom 
sleeve dipole antennas to define the RF field patterns with 
minimal impact by the external enviromnent. Such a sleeve 
dipole transfers almost 100% of the power whether a ground 
plane is used or not with the antenna. A summary of these 
findings is presented in the following list: 

Impedance match between the radio output and PA input 
was satisfactory but the match between the PA output 
and antenna was not. 

Stock antennas do not have a ground plane and their imped- 
ance is highly susceptible to objects near the antenna. 
When plugging the antenna into the PA, the impedance 
mismatch results in >8 dB of loss. 

Built custom sleeve dipole antennas for 433 MHz and 915 
MHz operation 

Custom antennas provide proper impedance match 
between the output of the PA and the antenna for maxi- 
mum power transfer. 

Procured ZX60-V82+PAs from Mini Circuits to provide 
up to +1 9 dBm (-100 mW) of output power at either 433 
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MHz or 915 MHz (which is lOx the CC1101 radio 
maximum output power) for improved range 

Achieved up to 2 km range by enclosing node in metal box 
for proper grounding and using sleeve dipole at base 
5 station 

In contrast to the sleeve dipole antennas, the performance 
of the standard whip antenna was also characterized when 
installing the antenna on a bulkhead connector mounted to a 
metal prototype node enclosure. In such a configuration, the 
to enclosure becomes the ground plane of the antenna and 
results in -1 dB of loss when connected to the PA and -2 dB 
of loss when connected to the radio directly (as compared to 
>8 dB loss without the enclosure). 

PATS Embedded Software 

15 The PATS embedded code for both the sensor and base 
station nodes may operate in Linux and/or TinyOS™. Tin- 
yOS™ includes a cross-compiler used to build executable 
files with the proper instructions for a specific target proces- 
sor (e.g., MSP430F2617 in this case). TinyOS™ additionally 
20 defines the packet format for the sensor and base station nodes 
and provides translation of the low-level packet format in 
TinyOS™ to the higher-level fields used by Java™ (which 
may be used for the PATS bridge code). Java SDK™ is the 
software development kit used to generate this conversion. 
25 TinyOS™ as a cross-compiler needs to define the target 
part, the pin I/O definitions and list of functions to use for 
compilation when making the executable file. The “make” 
command for the sensor node compilation has the form, 
“make patsl install .<node_ID>”, where node_ID is the node 
30 number associated with the executable file being built. The 
patsl file is a batch file that includes i) the target part number 
(PN), ii) the path for the list of code modules, iii) the top-level 
component (i.e. top-level code to be compiled), and iv) the 
path for the list of I/O specification files. This file is the 
35 TinyOS™ platform file (*.platform) and consists of these 
four elements. 

In TinyOS™, the component or top-level application 
specifies the top-level code, which is the definition of what is 
in the application. For PATS, there are three component 
40 types — sensor node, base station 915 MHz, and base station 
433 MHz. The platform file specifies the particular target part 
configuration (e.g. PATS sensor node, PATS 900 MHz base 
station node, etc.). So a given top-level application can be 
mapped to multiple target devices by using the appropriate 
45 platform file. In essence there are two directories used to build 
a particular executable including: i) the top-level application 
directory with the source code and “make” file for each appli- 
cation; and ii) the platform directory with the platform files to 
map a particular applications to a particular device. This 
50 mapping assumes that a particular component/top-level 
application can be supported by a given platform. This direc- 
tory mapping is shown FIG. 9. In other words, FIG. 9 illus- 
trates a TinyOS™ mapping between a top-level application 
(i.e. component) 902 and a low-level configuration (i.e. plat- 
55 form) 904. This architecture allows for mapping an applica- 
tion into multiple different physical devices (provided they 
are compatible) to make the application portable. 

Given the above architecture, TinyOS™ files are com- 
posed of a file pair including the source code and link files, 
60 where the link file provides the file name to the underlying 
module definition. This convention is followed for the plat- 
form file specification to provide path information. All Tin- 
yOS™ source files may be in nesC™ files and have the 
extension * .nc. nesC is a language that is an extension of C to 
65 support event-driven programming. During cross-compila- 
tion, the nesC code is translated to C, then compiled using gcc 
for the particular microcontroller. nesC code for TinyOS™ 
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may consist of modules (which implements a specific func- 
tion such as reading from the ADC), configurations (which 
integrates multiple modules into one component), and inter- 
faces (which define which functions of a component are call- 
able by other components). In the top-level application file, 
the line with “Main C” has the name of the top-level applica- 
tion and the line with “Boot. booted” is the entry point into the 
top-level code after boot up is complete. 

For the PATS implementation, the same node boardmay be 
used to implement both the PATS sensor node and PATS base 
station node. Consequently the same platform file is used for 
either PATS node type but the component file (i.e. top level 
application code) is different to delineate the functional dif- 
ference between the node types using the same physical plat- 
form. As a result, the embedded node code is embodied in two 
components (sensor and base station nodes) and one platform 
for the PATS node board. Incidentally, two additional com- 
ponents and one addition platform type may be used in alter- 
native versions of the node boards to implement master and 
slave 433 MHz base station nodes for testing of the onboard 
433 MHz radio. 

In view of the above, identical hardware may be used as a 
firefighter-held sensor node, relay node, and basestation 
node. Hence, different TinyOS™ applications are provided 
which enables the same hardware to perform these different 
roles. The four top-level applications used in PATS are: 

CTP_Diss_Tmp_GPS_Accel: This is the application that 
runs on PATS sensor nodes. Compile time parameters can set 
the radio rate, amplifier gain, etc. Executables for different 
sensor nodes are created by providing distinct node ids during 
compilation. 

BaseS tationPATS: This is the application that runs on the 
915 MHz PATS base station node. Compile time parameters 
can set the radio rate, amplifier gain, etc. 

BaseStation433 MHz: This is the application that runs on 
the 433 MHz PATS relay node connected to the 915 MHz 
PATS base station node (with a UART crossover cable). This 
may make use of a modified version of the TinyOS™ serial 
stack. 

BaseStation433 MHz _PC : This is the application that runs 
on the 433 MHz PATS relay node connected to the bridge PC 
(with a USB cable). This makes use of the standard TinyOS 
serial stack. 

nesC application code is cross-compiled for a specific 
“platform” 904. A platfonn specification defines the micro- 
controller and the peripheral driver libraries that can be used 
to compile applications for an embedded node. There are two 
“platforms” 904 defined for the PATS hardware. These are 

called “patsl” and “patsl 433mhz”. Such platforms can be 

directly used as a target for compiling (TinyOS™) applica- 
tions for the PATS nodes. Applications CTP_Diss_Tmp_GP- 
S_Accel and BaseStationPATS run on the patsl platform. 
Applications CTP BaseStations433 MHz and BaseSta- 
tion433 MHz_PC run on the patsl 433mhz platfonn. 

The microcontroller 602 on the PATS node may be pro- 
grammed using its JTAG interface. Further, a USB-based 
Flash programmer (e.g., TT s MSP-FET430UIF) may be used 
for this step. The machine code may be generated using a 
compiler tool chain provided as part of the TinyOS™ devel- 
opment environment. 

The 915 MHz radio 606A and power amplifier 620 may be 
controlled using a radio driver (e.g., the Blaze™ radio driver 
distributed with TinyOS™-contrib library). All radio com- 
munication parameters may be set by the embedded software 
at compile time including carrier frequency, bit rate, Rx filter 
bandwidth, modulation type, and Tx power. 
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The radio 606A in the PATS node (CC1 101) is interfaced 
with an RF front end chip (CC 1 1 90), which includes a power 
amplifier (PA), a low noise amplifier (LNA) and a transmit/ 
receive switch. In order to control the RF paths tothePA/LNA 
5 for transmit/receive functionality, control signals for the RF 
switch and enable lines for the PA and LNA are provided in 
the hardware design via GPIO (general purpose input/output) 
lines. In addition, the CC 1190 amplifier 620 has a gain control 
input line (to select between low and high gain modes). These 
10 RF switch controls and the gain control are generated from 
within the CC1 101 radio driver code The CC1 101 driver code 
may need to be modified to directly control the Rx/Tx switch 
control lines during the two-way communication. This is 
15 required since during multi -hop communication, a sender 
listens for an acknowledgement message after every trans- 
mission. 

In the 433 Mhz radio 606B, the CC1 101 radio with a 433 
MHz matching network is interfaced to the microcontroller 
20 602 using the SPI bus. This radio chip may be controlled 
using a standard Blaze™ driver since it does not have a power 
amplifier/LNA at its output (with associated RF switches). 

The OLED Display 610 (e.g., a NL128128C-EIF display) 
is used to display information in PATS. Exemplary embodi- 
25 ments of the OLED display 610 may be a 1" square 128x128 
pixel 1 8-bit color display using the OLED technology (i.e., a 
backlight does not have to be used as in conventional TFT- 
LCD displays). 

A TinyOS™ driver may be required to integrate the color 
30 graphic display with the handheld PATS sensor node. A driver 
may send commands to the driver controller chip using the 
SPI interface. Further, the driver may specify 1 6-bit color for 
each pixel Further, the driver may be configured to use all of 
the 128x128 pixels. 

35 The PATS display driver (in one or more embodiments) sup- 
ports the display of 5x8 pixel ASCII characters. 

An exemplary onboard accelerometer 604A for the PATS 
device may be the ADXL345 chip. This accelerometer 604A 
is capable of generating interrupts when it detects a free-fall 
40 and/or extended period of inactivity. This feature is used in 
the PATS nodes so that the X, Y, Z axis accelerometer mea- 
surements will not need to be continually transmitted. 
Instead, only the sensor measurements that meet the detection 
criteria is sent in the radio packet (Alert byte). The free-fall 
45 event is defined when all three axes of the accelerometer 
detect acceleration below a pre-defined acceleration level for 
a period of time (that is also pre-defined). An inactivity event 
is defined if the all three axes of the accelerometer experience 
a change in acceleration of less than a pre-defined value for 
50 more than a pre-defined time. Code may be used to set the 
acceleration levels and time period thresholds in the acceler- 
ometer 604A, and also to detect the interrupts when they are 
fired. These parameters can be easily changed according to 
the preferences of the firefighters. 

55 There are two UART ports from the microcontroller 602 
that are made available via headers on the PATS node. One of 
the ports has been programmed to interface with the GPS 
board 604C while the other UART port provides a bi-direc- 
tional data communication link to a PC via a USB-Serial 
60 adapter cable. 

The temperature sensor 604B is interfaced to the micro- 
controller 602 over a I2C bus. TinyOS™ drivers may be used 
to control this sensor. 

The flash memory chip 612 may be interfaced to the micro- 
65 controller 602 using the SPI bus. This chip 612 was tested to 
be functioning correctly but may not be integrated into the 
application code. 
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There are three LEDs (including alert LED 618 and Power 
LED 620) that are mounted on the main board that can be 
controlled by the microcontroller 602. The bright Alert LED 
618 that is attached to the daughter board is also controlled by 
the embedded code. 5 

Bridge Code/Software 

The PATS bridge code is a PC-based application. The 
application may run under a variety of operating systems and 
be programmed in a variety of programming languages (in- 
cluding Java™). This application is used to communicate to 
with the PATS base station node 114/208 connected to the PC 
214 to collect telemetry from the PATS mesh network and to 
send commands back into the PATS network from the com- 
mand console 116. It also connects to a TCP/IP socket as the 
mechanism to send the PATS telemetry to the remote SAP 15 
server 212 and to receive commands from the server 212 to 
relay them back to the PATS base station 114/208 for dissemi- 
nation to the appropriate PATS sensor node(s) 104/204. 

The steps to activate the bridge software on the Bridge PC 
214 are as follows. This assumes that the PC 214 has access to 20 
the Internet 216 and that the SAP server 212 is running (e.g., 
on a port that the PC 214 can communicate through). 

1 . Connect the PATS base station node 114/208 to the USB 

port. This should create a virtual COM port visible in the 
Device Manager. 25 

2. The SAP server’s (IP) address should be provided on the 
command line along with the virtual COM port con- 
nected to the PATS base station node 114/208. 

To simplify these steps, shortcuts can be created where 
these command line parameters are already specified. Then, 30 
simply clicking the shortcut will start the PATS bridge pro- 
gram. 

Situational Awareness and Prediction (SAP) Graphical User 
Interface 

The SAP user interface is the software that collects PATS 35 
sensor 104/204 measurements over a TCP channel, inserts it 
into a database, and presents the data overlaid over a map 
interface at the command center 116. The GUI interface sys- 
tem is a two-layer system that can also be used to relay 
messages from the command center 1 1 6 to the PATS sensor 40 
network 102. The user interface may be displayed on a variety 
of hardware devices 218 as described in further detail below. 

SAP server code may be written in the Java™ program- 
ming language and may execute within a Jetty™ web server. 
Whenever a session enters replay mode, two threads are 45 
spawned: 

A “replay” thread offers a server socket at which it acquires 
the requested replay activity information, simulating the 
operation of a base station thread. The thread records the 
acquired information in a list of the most recent replay 50 
updates for the nodes whose activity is being replayed. This 
information is returned to the client whenever the client (in 
replay mode) “polls” the server for node state information. 

A “replay driver” thread retrieves the requested replay 
activity information from the SAP database, connects to the 55 
replay thread, and transmits the retrieved update records to 
the replay thread at the requested rate, simulating the opera- 
tion of a PATS base station. 

The SAP GUI design accepts and transmits PATS sensor 
node packets, including relaying the position of individual 60 
firefighters with associated sensor information to a central- 
ized command display and the ability to send warning mes- 
sages back to the firefighters for alerts. The integration of a 
SAP interface with the PATS sensor network 10 includes: (i) 
presentation/suppression of the PATS node sensor labels via a 65 
settings dialogue button; (ii) inclusion of tabs to toggle 
between displays for the PATS nodes, white boarding capa- 
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bility and incident history; (iii) generate/ send broadcast mes- 
sages to all PATS nodes; (iv) maintain latest GPS latitude/ 
longitude when new GPS data is not available; and (v) 
maintain elapsed time when pausing data playback to resume 
with the proper time index. 

General database cleanup was also performed to support 
the new capabilities that were added to SAP. These involved 
updating all PATS records that contained an invalid GPS 
status along with removing records that contained a node 
number zero. Using remote processing capability (e.g., Ama- 
zon™ cloud machines) for both the SAP server and the 
MySQL™ database server made these kinds of adjustments 
very easy to accommodate. 

In making these modifications, the SAP architecture 
caused actions made by any user of the SAP browser interface 
to affect the actions on the interfaces of all other simultaneous 
SAP users. In particular, this could prevent a user from seeing 
real-time sensor data if another user had activated the replay 
mode on another browser. The architecture of the SAP inter- 
face isolates the actions of different users. Accordingly, prop- 
erties associated with the GUI include: 

Replays are per-client, so multiple different replays (at 
different speeds, etc.) can be viewed by different users 
while everybody else is watching the real-time stream. 

The alarm temperature that’s used for triggering UICDS 
(unified incident command and decision support) alerts 
is hard-coded in the server, as it needs to be known and 
stable in order for the UICDS alerts to be meaningful to 
UICDS users. Each SAP user can adjust warning tem- 
perature and alann temperature on the local client dis- 
play individually, to highlight areas of some temperature 
range of interest. 

UICDS alert conditions are detected at the server and 
immediately posted to UICDS; UICDS alert messages 
returned from UICDS are queued up individually to be 
polled by SAP clients, so each client sees all the mes- 
sages. 

A “Reset” button is in a global “Control messages” control 
panel. Since hitting “Reset” wipes out current real-time 
state for all nodes of the system, the location of the 
button avoids hitting “Reset” by mistake when trying to 
press “Clear”. 

The SAP server tracks PATS bridges individually, so a 
control message sent to “all nodes” will be conveyed to 
all nodes reachable through all bridges, not just the ones 
that are reachable through the most recently active 
bridge. 

The result of the above enables the SAP GUI to display data 
via a browser window that accesses the server via port 8080. 
The browser can be located on the same PC with the server or 
can be run on a remote machine and accesses the server via the 
Internet. Multiple browsers can access the server data simul- 
taneously from various locations. 

An example of the SAP graphical display is shown in 
FIGS. 10A-10B. More specifically, FIGS. 10A-10B showthe 
SAP GUI graphical display showing the “Earth-view” and 
localized locations of nodes in the theater of operation, alert 
status of nodes and pop-up display with detailed telemetry. 
FIG. 1 0A shows the display when the browser window is first 
opened. FIG. 10B shows a localized map of the sensor 
node(s) location with the map displayed on the left side. This 
“zoom in” function is accomplished by entering the desired 
node number in the text box 1002 at the left of the “Focus” 
button 1 004 at the top right of the di splay and then clicking the 
Focus button 1004 to zoom into the location for a particular 
node. Additional user controls are shown at the right of the 
display and can be used to set or clear 1006 alerts and send 
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text messages 1008 to individual sensor nodes or broadcast 
the messages to all nodes in the PATS mesh. 
Visualization/Computer Hardware 

FIG. 11 is an exemplary hardware and software environ- 
ment 1100 used to implement one or more embodiments of 5 
the invention (e.g., the Bridge 214, server 212, SAP visual- 
ization 218, and or other components of the system). The 
hardware and software environment includes a computer 
1102 and may include peripherals. Computer 1102 may be a 
user/client computer, server computer, or may be a database 10 
computer. The computer 1102 comprises a general purpose 
hardware processor 1104A and/or a special purpose hardware 
processor 1104B (hereinafter alternatively collectively 
referred to as processor 1104) and a memory 1106, such as 15 
random access memory (RAM). The computer 1102 may be 
coupled to, and/or integrated with, other devices, including 
input/output (I/O) devices such as a keyboard 1114, a cursor 
control device 1116 (e.g., a mouse, a pointing device, pen and 
tablet, touch screen, multi-touch device, etc.) and a printer 20 
1128. In one or more embodiments, computer 1102 may be 
coupled to, or may comprise, a portable or media viewing/ 
listening device 1132 (e.g., an MP3 player, iPod™, Nook™, 
portable digital video player, cellular device, personal digital 
assistant, etc.). In yet another embodiment, the computer 25 
1102 may comprise a multi-touch device, mobile phone, 
gaming system, internet enabled television, television set top 
box, or other internet enabled device executing on various 
platforms and operating systems. 

In one embodiment, the computer 1102 operates by the 30 
general purpose processor 1104 A performing instructions 
defined by the computer program 1110 under control of an 
operating system 1108. The computer program 1110 and/or 
the operating system 1108 may be stored in the memory 1106 
and may interface with the user and/or other devices to accept 35 
input and commands and, based on such input and commands 
and the instructions defined by the computer program 1110 
and operating system 1108, to provide output and results. 

Output/results may be presented on the display 1122 or 
provided to another device for presentation or further pro- 40 
cessing or action. In one embodiment, the display 1122 com- 
prises a liquid crystal display (LCD) having a plurality of 
separately addressable liquid crystals. Alternatively, the dis- 
play 1122 may comprise a light emitting diode (LED) display 
having clusters of red, green and blue diodes driven together 45 
to form full-color pixels. Each liquid crystal or pixel of the 
display 1122 changes to an opaque or translucent state to form 
a part of the image on the display in response to the data or 
information generated by the processor 1104 from the appli- 
cation of the instructions of the computer program 1110 and/ 50 
or operating system 1108 to the input and commands. The 
image may be provided through a graphical user interface 
(GUI) module 1118. Although the GUI module 1118 is 
depicted as a separate module, the instructions performing the 
GUI functions can be resident or distributed in the operating 55 
system 1108, the computer program 1110, or implemented 
with special purpose memory and processors. 

In one or more embodiments, the display 1 1 22 is integrated 
with/into the computer 1102 and comprises a multi-touch 
device having a touch sensing surface (e.g., track pod or touch 60 
screen) with the ability to recognize the presence of two or 
more points of contact with the surface. Examples of multi- 
touch devices include mobile devices (e.g., iPhone™, Nexus 
S™, Droid™ devices, etc.), tablet computers (e.g., iPad™, 

HP Touchpad™), portable/handheld game/music/video 65 
player/console devices (e.g., iPod Touch™, MP3 players, 
Nintendo 3DS™, PlayStation Portable™, etc.), touch tables, 
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and walls (e.g., where an image is projected through acrylic 
and/or glass, and the image is then backlit with LEDs). 

Some or all of the operations performed by the computer 
1102 according to the computer program 1110 instructions 
may be implemented in a special purpose processor 1 1 04B. In 
this embodiment, the some or all of the computer program 
1110 instructions may be implemented via firmware instruc- 
tions stored in a read only memory (ROM), a programmable 
read only memory (PROM) or flash memory within the spe- 
cial purpose processor 1 1 04B or in memory 1106. The special 
purpose processor 1104B may also be hardwired through 
circuit design to perform some or all of the operations to 
implement the present invention. Further, the special purpose 
processor 1104B may be a hybrid processor, which includes 
dedicated circuitry for performing a subset of functions, and 
other circuits for performing more general functions such as 
responding to computer program 1110 instructions. In one 
embodiment, the special purpose processor 1104B is an 
application specific integrated circuit (ASIC). 

The computer 1102 may also implement a compiler 1112 
that allows an application or computer program 1110 written 
in a programming language such as COBOL, Pascal, C++, 
FORTRAN, or other language to be translated into processor 
1104 readable code. Alternatively, the compiler 1112 may be 
an interpreter that executes instructions/source code directly, 
translates source code into an intermediate representation that 
is executed, or that executes stored precompiled code. Such 
source code may be written in a variety of programming 
languages such as Java™, Perl™, Basic™, etc. After comple- 
tion, the application or computer program 1110 accesses and 
manipulates data accepted from I/O devices and stored in the 
memory 1106 of the computer 1102 using the relationships 
and logic that were generated using the compiler 1112. 

The computer 1102 also optionally comprises an external 
communication device such as a modem, satellite link, Eth- 
ernet card, or other device for accepting input from, and 
providing output to, other computers 1102. 

In one embodiment, instructions implementing the operat- 
ing system 1108, the computer program 1110, and the com- 
piler 1112 are tangibly embodied in a non-transient com- 
puter-readable medium, e.g., data storage device 1120, which 
could include one or more fixed or removable data storage 
devices, such as a zip drive, floppy disc drive 1124, hard drive, 
CD-ROM drive, tape drive, etc. Further, the operating system 
1108 and the computer program 1110 are comprised of com- 
puter program 1110 instructions which, when accessed, read 
and executed by the computer 1102, cause the computer 1102 
to perform the steps necessary to implement and/or use the 
present invention or to load the program of instructions into a 
memory 1106, thus creating a special purpose data structure 
causing the computer 1102 to operate as a specially pro- 
grammed computer executing the method steps described 
herein. Computer program 1110 and/or operating instruc- 
tions may also be tangibly embodied in memory 1106 and/or 
data communications devices 1130, thereby making a com- 
puter program product or article of manufacture according to 
the invention. As such, the terms “article of manufacture,” 
“program storage device,” and “computer program product,” 
as used herein, are intended to encompass a computer pro- 
gram accessible from any computer readable device ormedia. 

Of course, those skilled in the art will recognize that any 
combination of the above components, or any number of 
different components, peripherals, and other devices, may be 
used with the computer 1102. 

FIG. 12 schematically illustrates a typical distributed com- 
puter system 1200 using a network 1204 to connect client 
computers 1202 to server computers 1206. A typical combi- 
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nation of resources may include a network 1204 comprising 
the Internet, LANs (local area networks), WANs (wide area 
networks), SNA (systems network architecture) networks, or 
the like, clients 1202 that are personal computers or worksta- 
tions (as set forth in FIGS. 1, 2, and 11), and servers 1206 that 5 
are personal computers, workstations, minicomputers, or 
mainframes (as set forth in FIGS. 1, 2, and 11). However, it 
may be noted that different networks such as a cellular net- 
work (e.g., GSM [global system for mobile communications] 
or otherwise), a satellite based network, or any other type of 10 
network may be used to comiect clients 1202 and servers 
1206 in accordance with embodiments of the invention. 

A network 1204 such as the Internet connects clients 1202 
to server computers 1206. Network 1204 may utilize ethemet, 1 . 
coaxial cable, wireless communications, radio frequency 
(RF), etc. to connect and provide the communication between 
clients 1202 and servers 1206. Clients 1202 may execute a 
client application or web browser and communicate with 
server computers 1206 executing web servers 1210. Such a 
web browser is typically a program such as MICROSOFT 20 
INTERNET EXPLORER™, MOZILLA FIREFOX™ 
OPERA™ APPLE SAFARI™, GOOGLE CHROME™, etc. 
Further, the software executing on clients 1202 may be down- 
loaded from server computer 1206 to client computers 1202 
and installed as a plug-in or ACTIVEX™ control of a web 25 
browser. Accordingly, clients 1202 may utilize ACTIVEX™ 
components/component object model (COM) or distributed 
COM (DCOM) components to provide a user interface on a 
display of client 1202. The web server 1210 is typically a 
program such as MICROSOFT’S INTERNET INFORMA- 30 
TION SERVER™. 

Web server 1210 may host an Active Server Page (ASP) or 
Internet Server Application Programming Interface (ISAPI) 
application 1212, which may be executing scripts. The scripts 
invoke objects that execute business logic (referred to as 35 
business objects). The business objects then manipulate data 
in database 1216 through a database management system 
(DBMS) 1214. Alternatively, database 1216 may be part of, 
or connected directly to, client 1202 instead of communicat- 
ing/obtaining the information from database 1216 across net- 
work 1204. When a developer encapsulates the business func- 411 
tionality into objects, the system may be referred to as a 
component object model (COM) system. Accordingly, the 
scripts executing on web server 1210 (and/or application 
1212) invoke COM objects that implement the business logic. 
Further, server 1206 may utilize MICROSOFT’S™ Transac- 45 
tion Server (MTS) to access required data stored in database 
1216 via an interface such as ADO (Active Data Objects), 
OLE DB (Object Linking and Embedding DataBase), or 
ODBC (Open DataBase Connectivity). 

Generally, these components 1200-1216 all comprise logic 50 
and/or data that is embodied in/or retrievable from device, 
medium, signal, or carrier, e.g., a data storage device, a data 
communications device, a remote computer or device 
coupled to the computer via a network or via another data 
communications device, etc . Moreover, this logic and/ or data, 55 
when read, executed, and/or interpreted, results in the steps 
necessary to implement and/or use the present invention 
being performed. 

Although the terms “user computer”, “client computer”, 
and/or “server computer” are referred to herein, it is under- 
stood that such computers 1202 and 1206 may be inter- 60 
changeable and may further include thin client devices with 
limited or full processing capabilities, portable devices such 
as cell phones, notebook computers, pocket computers, 
multi-touch devices, and/or any other devices with suitable 
processing, communication, and input/output capability. 65 

Of course, those skilled in the art will recognize that any 
combination of the above components, or any number of 
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different components, peripherals, and other devices, may be 
used with computers 1202 and 1206. 

Embodiments of the invention are implemented as a soft- 
ware application on a client 1202 or server computer 1206. 
Further, as described above, the client 1202 or server com- 
puter 1206 may comprise a thin client device or a portable 
device that has a multi-touch-based display. 

Logical Flow 

FIG. 13 is a flow chart illustrating the logical flow for 
tracking a position of one or more nodes in accordance with 
one or more embodiments of the invention. 

At step 1302, sensor information is captured from one or 
more sensors. Such sensor information may include a loca- 
tion (e.g., from a GPS module), a temperature (e.g., from a 
temperature sensor), and movement information (e.g., based 
on an accelerometer). The movement information (e.g., indi- 
cating a free-fall or extended period of inactivity) may trigger 
an alert condition. 

At step 1304, the sensor information is processed. 

At step 1306, the sensor information is relayed from the 
one or more nodes to a command center using a multi-hop 
packet routing protocol (e.g., that dynamically routing the 
sensor information through mobile sensor nodes using wire- 
less communication to a base station node). Each node has a 
first radio transceiver chip that operates at a first frequency 
range (e.g., in the 902-928 MHz industrial, scientific, and 
medical (ISM) band) and a second radio transceiver chip that 
operates at a second frequency range (e.g., a 400 MHz 
licensed band). The two chips enable each of the nodes to 
operate as either a mobile sensor node or a relay base station 
node. The ISM band radio chip provides the (relay) link (e.g., 
400 m) between two sensor nodes. Further, a power amplifier 
enables extended line-of-sight communication (i.e., increases 
the line-of-sight communication to 2 Km) between sensor 
nodes for the ISM band radio. 

Frequency hopping may be used for communication within 
the first frequency range and the second frequency range 
between the one or more nodes. The GPS module may pro- 
vide the time synchronization needed to maintain time slots 
for the frequency hopping. In other words, to operate at higher 
powers, the nodes may implement frequency hopping so that 
communication in each band is limited to a defined time 
duration (e.g., 40 ms). The system may further integrate the 
spatial multi -hopping protocol (e.g., CTP) with the frequency 
hopping protocol to provide a spatial multi-hopping system 
with a defined range (e.g., ~2 km) at each hop. Alternatively, 
the nodes may operate without the frequency hopping and 
instead may transmit power to a maximum of 1 mW (e.g., for 
a few hundred meters range at each hop). In view ofthe above, 
the system autonomously (e.g., without user intervention) 
routes the sensor information and alert information via a 
self-organizing network. For example, a node may collect 
temperature, acceleration, and the GPS location to signal a 
downed first responder without user intervention. 

The command center receives the sensor information from 
the nodes, transmits the alert information (e.g., text message 
and/or audible/visual alarm) to the nodes, and may also be 
configured to display the sensor information overlaid on a 
map (e.g., on a web browser based graphical user interface). 
Thus, the status of first responders may be visualized on 
command computers, a web browser, portable tablets, etc. 

At step 1308, alert information (e.g., a text message) is 
received from the command center. 

At step 1310, the alert information is displayed on a dis- 
play. Alternatively, the alert information may be audible and/ 
or visible alarms (e.g., blinking light). 

As described above, the first radio transceiver chip, the 
second radio transceiver chip, the power amplifier, and the 
one or more sensors are integrated into a single circuit board. 
Further, the display, alert switch, alert LED, and mating 
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extension headers may be housed on a separate daughter 
board. A node may also have a connector to enable USB 
communication via serial-USB cable. 

In view of the above, first responders are empowered with 
real-time data fusion and situational awareness from a het- 
erogeneous network of sensors. Active surveillance of rel- 
evant information for each first responders is conducted and 
there is collaborative sharing of all information between mul- 
tiple front line organizations. Geospatial mapping and the 
fusion of multiple sensor web information are used. Further, 
real-time visualization of sensor information may be pro- 
vided on portable devices (e.g., on a laptop and/or on the node 
display). In this regard, embodiments of the invention may 
also provide the capability to connect a node to an external 
cell phone (or laptop/tablet) display using Bluetooth (or other 
communication methods). Once connected, alert messages 
from the node can be displayed on a selected Bluetooth 
device. 

Conclusion 

This concludes the description of the preferred embodi- 
ment of the invention. The following describes some alterna- 
tive embodiments for accomplishing the present invention. 

The foregoing description of the preferred embodiment of 
the invention has been presented for the purposes of illustra- 
tion and description. It is not intended to be exhaustive or to 
limit the invention to the precise form disclosed. Many modi- 
fications and variations are possible in light of the above 
teaching. It is intended that the scope of the invention be 
limited not by this detailed description, but rather by the 
claims appended hereto. 
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What is claimed is: 

1. A personal alert and tracking system comprising one or 
more nodes, wherein each of the one or more nodes com- 
prises: 

(a) a first radio transceiver chip operating at a first fre- 
quency range and a second radio transceiver chip oper- 
ating in a second frequency range, wherein: 

(1) the first radio transceiver chip and the second radio 
transceiver chip enable the node to operate as either a 
mobile sensor node or a relay base station node; 

(2) the second radio transceiver chip provides a relay 
link between the one or more nodes; 

(b ) a power amplifier that increases a line-of-sight commu- 
nication between the one or more nodes; 

(c) one or more sensors for providing sensor information, 
wherein the one or more sensors comprise: 

(1) a global positioning system (GPS) module for pro- 
viding a location; 

(2) a temperature sensor for determining a temperature; 
and 

(3) an accelerometer for triggering an alert condition; 

(d) a first display for displaying alert information; 

(e) embedded software configured to: 

(1) capture and process the sensor information; 

(2) provide a multi-hop packet routing protocol to relay 
the sensor information to a command center; 

(3) receive alert information from the command center; 
and 

(4) display the alert information on the display. 
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2 . The personal alert and tracking system of claim 1 , 
wherein the first frequency range comprises a 902-928 MHz 
industrial, scientific, and medical (ISM) band. 

3 . The personal alert and tracking system of claim 1 , 

5 wherein the second frequency range comprises a 400 MHz 

licensed band. 

4 . The personal alert and tracking system of claim 1 , 
wherein frequency hopping is used for communication within 
the first frequency range and the second frequency range 

111 between the one or more nodes. 

5 . The personal alert and tracking system of claim 4 , 
wherein the GPS module provides time synchronization 
needed to maintain time slots for the frequency hopping. 

15 6. The personal alert and tracking system of claim 1, 

wherein the alert condition comprises a free-fall or extended 
period of inactivity. 

7 . The personal alert and tracking system of claim 1 , 
wherein the alert information comprises a text message. 

20 8. The personal alert and tracking system of claim 1, 

wherein: 

the first radio transceiver chip, the second radio transceiver 
chip, the power amplifier, and the one or more sensors 
are integrated into a single circuit board; and 

25 the display is housed on a separate daughter board. 

9. The personal alert and tracking system of claim 1, 
wherein the multi-hop packet routing protocol comprises 
dynamically routing the sensor information through the one 
or more mobile sensor nodes using wireless communication 

30 to a base station node. 

10. The personal alert and tracking system of claim 1, 
wherein the command center is configured to: 

receive the sensor information from the one or more nodes; 

transmit the alert information to the one orrnore nodes; and 

35 display the sensor information overlaid on a map. 

11 . The personal alert and tracking system of claim 10 , 
wherein the display is performed on a web browser based 
graphical user interface. 

12 . The personal alert and tracking system of claim 1 , 

40 wherein the system autonomously routes the sensor informa- 
tion and alert information via a self-organizing network. 

13. A method for tracking a position of one or more nodes 
comprising: 

(a) capturing sensor information from one or more sensors 

45 by: 

(1) determining a location from a global positioning 
system (GPS) module; 

(2) determining a temperature using a temperature sen- 
sor; and 

50 (3) determining movement information based on an 

accelerometer; 

(b) processing the sensor information; 

(c) relaying the sensor information from one or more nodes 
to a command center using a multi-hop packet routing 

55 protocol, wherein: 

(1 ) each node has a first radio transceiver chip that oper- 
ates at a first frequency range; 

(2) each node has a second radio transceiver chip that 
operates at a second frequency range; 

60 (3) the first radio transceiver chip and the second radio 

transceiver chip enable each of the nodes to operate as 
either a mobile sensor node or a relay base station 
node; 

(4) the second radio transceiver chip provides a relay 

65 link between the one or more nodes; 

(5) a power amplifier increases a line-of-sight commu- 
nication between the one or more nodes; 
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(d) receiving alert information from the command center; 
and 

(e) displaying the alert information on a display. 

14. The method of claim 13, wherein the first frequency 
range comprises a 902-928 MHz industrial, scientific, and 5 
medical (ISM) band. 

15. The method of claim 13, wherein the second frequency 
range comprises a 400 MHz licensed band. 

16. The method of claim 13, wherein frequency hopping is 10 
used for communication within the first frequency range and 
the second frequency range between the one or more nodes. 

17. The method of claim 16, wherein the GPS module 

provides time synchronization needed to maintain time slots 
for the frequency hopping. 15 

18. The method of claim 13, further comprising triggering, 
via the movement information indicating a free-fall or 
extended period of inactivity, an alert condition. 

19. The method of claim 13, wherein the alert information 
comprises a text message. 
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20. The method of claim 13, wherein: 

the first radio transceiver chip, the second radio transceiver 
chip, the power amplifier, and the one or more sensors 
are integrated into a single circuit board; and 

the display is housed on a separate daughter board. 

21 . The method of claim 13, wherein the multi-hop packet 
routing protocol comprises dynamically routing the sensor 
information through the one or more mobile sensor nodes 
using wireless communication to a base station node. 

22. The method of claim 13, wherein the command center 
is configured to: 

receive the sensor information from the one or more nodes ; 

transmit the alert information to the one or more nodes ; and 

display the sensor information overlaid on a map. 

23. The method of claim 22, wherein the display of the 
sensor information is performed on a web browser based 
graphical user interface. 

24. The method of claim 13, wherein the system autono- 
mously routes the sensor information and alert information 
via a self-organizing network. 



